What Defaults can do that Hierarchies Can't

ion Truth level Plan value 1 through(D1), through(D2), go-to(table) d2t 2 open(D1), through(D1), open(D2), through(D2), dt go-to(table) 3 go-to(D1), open(D1), through(D1), go-to(D2), t open(D2), through(D2), go-to(table) Table 2: Re ning plans 2.2 Treatment using defaults Base-level default knowledge can reproduce this hierarchical decomposition without resorting to the use of a specialized representation language. In the above example, we simply provide information indicating that certain subgoals are likely to be easily achieved: achievable(open(x)) [d2t] achievable(next-to(d)) [dt] (1) Our notation here is that dt corresponds to a rst-order default, d2t to a second-order default, and so on. The commonsense meaning of the rst default in (1) is that we can open any door, and the second means that we can easily get to any object in our current room. The di erent default values of dt and d2t are used to indicate that we are more certain of our ability to navigate around a particular room than to open a door. To use the information in (1), suppose that the form of the axiom telling us when an action succeeds is as follows: occurs(a) ^ [8p:prec(p; a) sat(p)] succeeds(a) holds(p) sat(p) (2) Di erent declarative systems will obviously represent actions di erently, but this seems a reasonable choice. An action succeeds if it occurs and its preconditions are satis ed; a speci c precondition is satis ed if it holds in the situation in question. This description is the one actually used in [5, 7], with the modi cation that a modal operator is used to minimize the extent of the predicate prec. We can now modify (2) to become the following: holds(p) _ achievable(p) sat(p) (3) As we will see in Proposition 2.1, this has exactly the desired e ect of capturing the hierarchy in our declarative setting. Both of the defaults in (1) are base-level information about the planning domain and can now be used to control the planner's search. Speci cally, the search for a plan that has truth value d2t can essentially ignore the question of whether doors are open and where in the room a particular object is; the subsequent search for a re ned plan with truth value dt will ignore only the question of where objects are within rooms. Somewhat more speci cally, plan 1 in Table 2 has truth value d2t, plan 2 has truth value dt and plan 3, which is guaranteed to succeed, has truth value t. The two default statements cause the declarative planner to generate partial plans that are identical to the ones generated by a traditional hierarchical planner. We can also mechanize the process of turning an abstrips hierarchy into a set of defaults: In abstrips, relations are assigned priorities; when solving the problem, the relations are considered in order of decreasing priority. In the example we are considering, the open predicate would be assigned a value of 2 and the next-to predicate a value of 1. In other words, the initial plan can ignore all instances of open or next-to as preconditions; the rst re nement can ignore instances of next-to. Proposition 2.1 Suppose that an abstrips system labels each of its predicates pi with a priority vi. Then the functioning of abstrips can be duplicated using the defaults achievable(pi) [dvit] (4) Proof. Suppose that the highest priority assigned by the system is m. Then at iteration k, abstrips will produce a plan that ignores all preconditions with priority less than or equal to m k; we need to show that this is identical to the problem of nding a declarative solution to the planning problem that succeeds with truth value dm kt. To see this, let a be any action that occurs as part of such a plan. We claim that a will succeed with truth value djt if and only if a succeeds while ignoring all preconditions of priority j or less; the proposition will then follow. But this is an immediate consequence of (3): If a succeeds when ignoring preconditions of priority j or less, since each of these preconditions is achievable with truth value djt, we can use (3) to prove (also with truth value djt) that the action succeeds. Conversely, if we can prove that the action succeeds with truth value djt or better, it must be the case that the only achievability assumptions used defaults with truth value dit for i j, so that we are ignoring only preconditions of priority j or less. In making this argument, we are using the fact that there is no way to derive :achievable(p) from other information in our database, so all of the relevant achievability assumptions hold at any particular level of the default hierarchy. Proposition 2.1 shows that we can always continue to enjoy the computational bene ts of hierarchical planning in a declarative setting.2 Deducing control information from base-level knowledge about the domain (default statements about preconditions) allows us to select our hierarchy automatically. Sipe and nonlin, for instance, do not address the problem of classifying operator preconditions into lters and subgoals (Wilkins calls them preconditions and subgoals [16]). Filters are preconditions to an action which the planner should not, for heuristic reasons, plan to achieve. Subgoals are preconditions that the planner should try actively to achieve. The classi cation of preconditions into lters and subgoals in these classical planners is generally left for the user to solve in an ad hoc manner, using a hierarchy or in some other fashion. 2Note that we are assuming that it is possible to use our declarative system to draw default conclusions without performing the consistency check required by most formalizations of nonmonotonic reasoning. This is to be expected; the original arguments in [6] suggest that the computational benets associated with nonmonotonicity are a result of the search focus provided by default conclusions when the consistency check is not performed. An implemented system that behaves in this fashion is discussed in [7]. Action Preconditions E ects go-through(d) in(r1) :in(r1) door(d; r1; r2) in(r2) open(d) next-to(d) make-open(d) in(r1) open(d) next-to(d) door(d; r1; r2) unlocked(d) go-to(x) location(x; r) :next-to(y) in(r) unlock(d) key(k; d) unlocked(d) holding(k) next-to(d) take(k) cabinet(k; c) holding(k) next-to(c) :cabinet(k; c) Table 3: Actions in the extended robot world Given base-level default information about the achievability of certain predicates, the deferrable preconditions of an operator become precisely those for which achievability can be proven by default. The problem of distinguishing lters from subgoals thus becomes one of correctly stating the base-level assertions. Provided that the default assertions fairly represent our knowledge about the world, we expect that the induced hierarchy of actions will also be correct. Similar claims are made for the derivation of control knowledge generally in [8]. 3 Beyond simple hierarchies We now extend our example in a way that reveals some limitations of conventional hierarchical descriptions, and go on to show that default information can be used to avoid these limitations. 3.1 Extending the example We complicate the world of the robot a bit, adding cabinets in every room and specifying that doors have locks on them. Inside the cabinets are keys that unlock the doors, although there is no guarantee that the cabinet in any particular room will contain the keys to that room's doors. The actions in our extended domain appear in Table 3. We can unlock any door we are next to, if we have the key. We can take a key if it is in a cabinet that we are next to. The problem of opening a door d now becomes much more subtle. If d is locked, we need to nd a path through unlocked doors to the cabinet that contains d's key. 3.2 The failure of static hierarchies Consider now the problem of writing a set of hierarchical operators corresponding to the primitive actions available to our robot. It is clear that we must consider the type predicates key and door to be of the highest criticality, since they are unchanged by any actions we might perform. With a little thought, it becomes clear that the in precondition of the go-through operator clearly should also be planned for early. What about the open precondition of the go-through operator? If we continue to let open have a lower priority than in, the openness of doors will only be considered after planning a complete route from start to nish. However, this ordering is likely to result in an abstract plan that we will be unable to expand. In expanding a plan that involves opening a locked door for which we have no key, the planner will generate a subplan for the robot to go to another room, retrieve the key and come back to the rst locked door. This subplan will set o a cascade of sub-subplans for retrieving the keys to the locked doors that the robot runs into while on its rst subtask and so on; if the planner succeeds in solving its problem this way, it will be by blind luck more than anything else. Any plan found is almost guaranteed to be disastrously baroque. Note that this problem arises if the planner even once makes an incorrect assumption that a door will be easily opened. This is obviously quite likely for any plan that takes us through many doors. 3.3 Solutions in the static model If we are committed to the conventional description of hierarchies, we can salvage it in one of two ways. We can abandon the hierarchy altogether, or split one of our operators into two. 3.3.1 Abandon By giving open a high criticality value, we can choose to never defer it. Our abstract plans will no longer su er from the \cascade" e ect, but abandoning the hierarchy will cause us to lose the computational bene ts of hierarchical planning. This seems not to be a viable solution for computational reasons, especially if most of the doors are unlocked. 3.3.2 Split The other option is to split the go-through operator into two. One operator tells how to walk through easy doors; the other tells how to walk through hard doors. Assuming that our representation allows it, go-through-easy-door will give open a low criticality value, and will have lters making the rule applicable only if the door is unlocked or a key can easily be retrieved. go-through-hard-door will give open a high criticality value and will have lters guaranteeing that it is only applied when the door is in fact di cult to open. This will guarantee that we only defer open when it really is deferrable, avoiding the problem of Section 3.2. An alternative but equivalent split creates the operators unlock-with-key, which unlocks doors for which we have the key or can get it easily, and unlock-without-key, which deals with the more di cult situation. But now suppose that we have another precondition to go-through that is also sometimes deferrable and sometimes not. Perhaps it is easy to get next to most doors, but for some next-to is a problem because there are obstacles obstructing the path to the door; moving the obstacles might require retrieving tools from other rooms. We now have the same problem with next-to that we did earlier with open: If we always defer next-to, a new cascade of subgoals makes it unlikely that we solve our original problem. If we never defer next-to, we lose the computational advantages of hierarchy. Sometimes deferring next-to forces us to split the go-through action into two again. Since we have already split this action along the easy-door/hard-door axis, the new split will result in four subactions. The following result is immediate: Proposition 3.1 If an action has n preconditions, each of which is deferrable in some situations but not in others, a static hierarchy may need to split the action into 2n subtypes in order to plan e ectively. Note that it is not only the size of the domain description that is growing exponentially here; by introducing more actions we are also increasing the planner's branching factor from n to 2n. We see from this that splitting the operators used by conventional hierarchical planners is not an attractive option in general. 3.4 Solution in the declarative model In the declarative approach, solving this problem is trivial. If a predicate pi should be given priority vi but only in the situation si, we need merely replace (4) with si achievable(pi) [dvit] (5) The si's appearing here will refer to various features of our domain; one instance of (5) might be holding(k) ^ key(k; d) achievable(unlocked(d)) (with truth value djt for some j), saying that we don't have to worry about unlocking a door for which we already have the key. Given this axiom, note that we will assume that we can unlock d if there are other actions, also succeeding with truth value djt or better, that manage to establish si. So if we continue to make next-to the least critical of our preconditions, we can easily plan to collect keys and use them before worrying about the details of approaching the cabinets in which speci c keys are contained. Situation-dependent hierarchies arise in other settings as well. Consider the original axiomatization of our robot's world once again, where we indicated that opening a door d had three preconditions: that the robot be in the same room as d, that it be next to d, and that d be a door. The rst of these preconditions is in some sense irrelevant, since the robot can't be next to d unless it is in the same room as d is. Irrelevant though it may be from a declarative point of view, the precondition is crucial to a hierarchical planner working in this domain. To see why, recall that when constructing a plan that succeeds only by default, we ignore any precondition involving next-to. When we do this, the make-open action will have only a single precondition { that the object being opened be a door. The result is that the robot, trying to get to the table in Figure 1, may form the plan of rst opening both doors and only then walking to B, C and the table! By including the dummy in precondition to the make-open action, we ensure that the robot, when constructing the default plan, cannot expect to open a door d unless itis in the same room as d is.The declarative approach provides us a much cleaner way of achieving this a ect.Instead of saying thatachievable(next-to(d))is true by default, we say thatlocation(d; r) ^ in(r) achievable(next-to(d))(6)is true by default. This really captures the sense of the default: We can maneuvernext to any object in our current room, but not necessarily next to other objects inthe domain.There are a variety of advantages to this formulation. First, existing methodsrequire us to add a dummy in precondition to every action that has a next-toprecondition; it is obviously simpler to merely replace (1) with (6).Second, there are domains that are awkward to describe using the dummy precon-ditions needed by static hierarchies. Imagine that our domain contains some invisibleobjects, and the default we want to introduce says that we can only maneuver nextto visible objects in our current room.If we want to avoid splitting our actions into subtypes depending on the visibilityof the door or other objects involved, we will need to introduce a dummy visibleprecondition. But this is unfaithful to the sense of the original domain description,which permitted us to open invisible doors if we could somehow manage to maneuvernext to them.These collected observations suggest another way of looking at Proposition 3.1.What we have seen is that the question of the criticality or priority to be assigned toa precondition is one that requires us to do some reasoning. How hard is it to opena door or get next to it? A static hierarchy such as that used by existing planningsystems cannot do this kind of reasoning, and must determine the priorities by lookupalone.Of course, there is a standard way to ensure that no reasoning is needed to solvea problem: Instead of working with the existing axiomatization, use its deductiveclosure. This guarantees that no inference will be needed in determining the prioritylevels, but the deductive closure of a database consisting of sentences like (5) canbe expected to be of size exponential in the size of the original database. This iswhy the number of action subtypes grows exponentially with the number of splitpreconditions.In some cases, of course, computing the deductive closure of a declarative databasecan save a great deal of e ort at runtime; it might be very di cult to backward chainthrough rules like (5) to determine what priority should be assigned to a predicate insome particular situation. This seems unlikely to be true in planning examples, how-ever, since the priority determination can be expected to depend in a fairly straightfor-ward way on the values taken by situation-dependent variables (is the door locked?).In those cases where signi cant inference is needed to get from situational informa-tion to criticality values, we can still choose to forward-chain on the rules being usedwithout splitting our actions into a catastrophic number of subtypes. 4 ConclusionLifschitz proves in [12] that any system making the strips assumption will havedi culty dealing with the rami cation problem. Wilkins acknowledges that such asystem cannot be powerful enough to encode complex control knowledge: \Systemssuch as sipe that do hierarchical planning can use abstract operators to encode somemetaplanning knowledge, but . . . the most interesting metaplanning ideas cannot beencoded in this manner" [15]. In this paper, we have con rmed Wilkins' statement,shown that the problem is closely related to the need to split strips operators intosubtypes to solve the rami cation problem, and proposed a way to use base-leveldefault information to overcome these di culties. Atomic defaults can be used tocapture existing hierarchical notions, while compound default sentences can be usedto represent hierarchies that have previously eluded formulation.Other authors have also considered these issues, although their work has a a-vor rather di erent from ours. Feldman and Morris discuss the distinction betweenlters and subgoals in [2], but their analysis focuses on the detection of loops in plan-ning search and leaves the question of hierarchy unaddressed. Knoblock discussesthe automatic derivation of a planning hierarchy in [10], but the methods used areprimarily syntactic and are concerned with the development of a static hierarchy inany event. Smith and Peot suggest that Knoblock's analysis should focus on moresemantic features in [14] but they, too, limit their attention to static hierarchies.This is to be expected; it seems impossible to incorporate dynamic hierarchies intonondeclarative planners. Although it is true that declarative planning has problemsof its own, the analysis we have presented shows that it also has important capabilitiesthat nondeclarative methods lack.AcknowledgmentThis work has been supported by the Air Force O ce of Scienti c Research undergrant number 90-0363, by NSF under grant number IRI89-12188 and by DARPA/RomeLabs under grant number F30602-91-C-0036, and by an Air Force Graduate Labora-tory Fellowship from Rome Labs. We would like to thank Don Geddis, Will Harveyand the other members of Stanford's principia group for helpful discussions on thiswork. Subbarao Kambhampati pointed out the relationship of Feldman and Morris'swork to our own.References[1] A. B. Baker. Nonmonotonic reasoning in the framework of situation calculus.Arti cial Intelligence, 49:5{23, 1991.[2] R. Feldman and P. Morris. Admissible criteria for loop control in planning. InProceedings of the Eighth National Conference on Arti cial Intelligence, pages151{157, 1990.[3] R. Fikes and N. J. Nilsson. STRIPS: A new approach to the application oftheorem proving to problem solving. Arti cial Intelligence, 2:189{208, 1971. [4] J. J. Finger. Exploiting Constraints in Design Synthesis. PhD thesis, StanfordUniversity, Stanford, CA, 1987.[5] M. L. Ginsberg. Computational considerations in reasoning about action. InProceedings of the Second International Conference on Principles of KnowledgeRepresentation and Reasoning, Boston, MA, 1991.[6] M. L. Ginsberg. The computational value of nonmonotonic reasoning. In Pro-ceedings of the Second International Conference on Principles of Knowledge Rep-resentation and Reasoning, Boston, MA, 1991.[7] M. L. Ginsberg. Modality: The key to practical knowledge representation. Tech-nical report, Stanford University, 1992.[8] M. L. Ginsberg and D. F. Geddis. Is there any need for domain-dependent controlinformation? In Proceedings of the Ninth National Conference on Arti cialIntelligence, 1991.[9] M. L. Ginsberg and D. E. Smith. Reasoning about action I: A possible worldsapproach. Arti cial Intelligence, 35:165{195, 1988.[10] C. A. Knoblock. Learning abstraction hierarchies for problem solving. In Proceed-ings of the Eighth National Conference on Arti cial Intelligence, pages 923{928,1990.[11] R. E. Korf. Macro-operators: A weak method for learning. Arti cial Intelligence,26:35{77, 1985.[12] V. Lifschitz. On the semantics of STRIPS. In Proceedings of the 1986 Workshopon Planning and Reasoning about Action, Timberline, Oregon, 1986.[13] E. D. Sacerdoti. A Structure for Plans and Behavior. American Elsevier, NewYork, 1977.[14] D. E. Smith and M. Peot. A critical look at Knoblock's hierarchy mechanism.Unpublished manuscript, 1992.[15] D. E. Wilkins. Domain-independent planning: Representation and plan genera-tion. Arti cial Intelligence, 22:269{301, 1984.[16] D. E. Wilkins. Practical Planning: Extending the Classical AI PlanningParadigm. Morgan Kaufmann, San Mateo, CA, 1988.